成人无码网www在线观看-久激情内射婷内射蜜桃-亚洲欧美日韩久久精品-婷婷五月综合激情

QQ會員活動運營平臺（AMS），是QQ會員增值運營業(yè)務(wù)的重要載體之一，承擔(dān)海量活動運營的Web系統(tǒng)。在過去四年的時間里，AMS日請求量從200-500萬的階段，一直增長到日請求3-5億，最高CGI日請求達到8億。在這個過程中，AMS在架構(gòu)方面發(fā)生了大幅度的調(diào)整和變遷，我們走過了一段非常難忘的技術(shù)歷程。

本文將會分享QQ會員活動運營平臺的架構(gòu)設(shè)計實踐，希望對做技術(shù)的同學(xué)有所幫助。

一、海量活動運營的挑戰(zhàn)和我們的應(yīng)對思路

一個產(chǎn)品業(yè)務(wù)的發(fā)展總是離不開運營二字，而運營的表現(xiàn)形式很多會體現(xiàn)到活動需求上，越是重運營的產(chǎn)品業(yè)務(wù)，通常會產(chǎn)生越多的活動運營開發(fā)需求。

當(dāng)我們說起“活動”，很多人的第一反應(yīng)會覺得這是一個并不會有很多技術(shù)難度的一個東西。通常來說，如果我們只做1-2個活動，那的確是沒有太多技術(shù)難度的，但是，如果我們將這個量級提升到做1000個活動，甚至更多的時候，這就成為一個的技術(shù)難題。

1. 活動運營業(yè)務(wù)的挑戰(zhàn)和難題

（1）騰訊SNG增值業(yè)務(wù)面臨海量活動運營開發(fā)的挑戰(zhàn)

騰訊的增值產(chǎn)品部在QQ會員體系、游戲運營、個性化等各個業(yè)務(wù)上都需要持續(xù)高強度的運營性活動來促進用戶的拉新、活躍和留存，這里本身已經(jīng)產(chǎn)生了非常多的運營需求。而且，自2014年開始，隨著移動互聯(lián)網(wǎng)邁向成熟階段，手Q平臺上的手游運營需求大爆發(fā)，一個月需要上線的活動出現(xiàn)數(shù)倍的增長。

（2）活動開發(fā)的復(fù)雜性

開發(fā)一個活動本身需要一定的工作量。尤其是大型的推廣活動，這類型的活動對功能和性能的要求比較高。一個典型的大型活動通常有數(shù)千萬的用戶參與，因此，對性能要求比較高，如果再涉及到“秒殺”或者“搶購”類型的高并發(fā)功能時，對于基礎(chǔ)支撐系統(tǒng)是一個強力的挑戰(zhàn)。

活動功能眾多，包括禮包、抽獎、分享、邀請、兌換、排行、支付等，這些不同的參與和表現(xiàn)形式，也會涉及更多的后端接口通信和聯(lián)調(diào)。例如，我們的游戲運營業(yè)務(wù)涉及上百款游戲，而不同的游戲?qū)?yīng)不同的服務(wù)接口，就游戲相關(guān)的通信接口，就涉及上千個。

還有一個非常重要的問題，就是活動運營的安全和可靠性。因為，我們的活動，大多涉及較重要的實物獎品發(fā)放，如iphone、ipad等高價值禮包，對安全要求很高。

（3）活動運營開發(fā)人力難題

傳統(tǒng)手工開發(fā)模式，普通活動也需要1周的開發(fā)周期，而典型大型活動更是需要1-2周開發(fā)周期，開發(fā)和測試工作量繁重。并且，很多活動是在指定節(jié)假日推廣，通常有嚴(yán)格上線時間要求。在緊迫并且快速增長的運營需求面前，人力非常有限。

目前，全年活動上線超過4300個。

2. 活動本質(zhì)和我們的方法論

通過對不同業(yè)務(wù)的活動模式的分析和抽象，我們發(fā)現(xiàn)事實上絕大部分活動都可以用一組“條件”和“動作”的方式進行抽象和封裝，進而形成通用的“條件”（Rule）和“動作”（Operation）活動組件，不同條件和動作的組合使用，變成活動邏輯的實現(xiàn)。然后，我們希望通過平臺化和框架驅(qū)動開發(fā)的方式，將這些組件統(tǒng)一封裝。同時，在框架和平臺層面，為活動組件的運行提供高可靠、高性能、具備過載保護和水平擴展能力的框架支撐環(huán)境。

活動組件只需要封裝自身業(yè)務(wù)邏輯，核心功能框架自動支持，從而實現(xiàn)活動運營開發(fā)的徹底自動化。

AMS所需要承擔(dān)的任務(wù)，就是實現(xiàn)這個規(guī)劃。需要面臨的，主要是解決三個方面的問題：

（1）建設(shè)高效活動開發(fā)模式（運營開發(fā)自動化）。

（2）搭建高可靠性和高可用性的運營支撐平臺。

（3）保證活動運營業(yè)務(wù)的安全。

二、構(gòu)建高效活動運營開發(fā)模式

2012年初，也就是在AMS產(chǎn)生之前的活動開發(fā)模式，相對比較隨意，也并沒有一套嚴(yán)格和完整的框架支持，組件的復(fù)用程度不夠高。因此，我們開發(fā)一個活動，經(jīng)常需要耗時1周多。當(dāng)時，開發(fā)活動的其中一個特點就是“各自為政”，每個運營開發(fā)同學(xué)，各自產(chǎn)生了一批前端和后端組件，CGI層也產(chǎn)生了很多不同規(guī)則的入口。這些各自實現(xiàn)的組件，結(jié)構(gòu)比較凌亂，不成體系，維護起來也比較困難。最重要的是，這樣的組件對于活動開發(fā)來說，使用復(fù)雜，復(fù)用率低，以至于開發(fā)效率也比較低。

在當(dāng)時，活動運營需求也出現(xiàn)了一定程度上的堆積，很多需求沒有人力支持，產(chǎn)品同學(xué)也覺得我們上線活動比較慢。

1. 系統(tǒng)架構(gòu)分層和統(tǒng)一

基于這個問題，我們當(dāng)時想到的第一個解決方案，就是整合前端和后端組件，重新搭建一個結(jié)構(gòu)清晰和統(tǒng)一的系統(tǒng)。將這個系統(tǒng)的接口分層、復(fù)用、簡化的原則，逐步構(gòu)建一個完整的體系。而且，從我們開發(fā)的角度來說，最重要的目的，是為減少活動開發(fā)的工作量，解放開發(fā)人員，提升研發(fā)效率。

我們的前端組件通過一個叫Zero的框架統(tǒng)一整合，前端每一個功能以組件的形式出現(xiàn)，統(tǒng)一維護和復(fù)用。CGI層則進行了代碼重構(gòu)，實行框架驅(qū)動式開發(fā)，將每一個業(yè)務(wù)邏輯功能，收歸到一個唯一的入口和統(tǒng)一的體系中。核心功能框架自動支持，已有活動功能組件可直接配置使用。如果沒有新的功能接入，運營開發(fā)只需要配置一份簡單的參數(shù)，就可以完成后端功能邏輯，不再需要寫代碼。對于基礎(chǔ)支撐服務(wù)，則以平臺化的模式進行管理，做統(tǒng)一接入和維護。

當(dāng)我們做完系統(tǒng)結(jié)構(gòu)的調(diào)整后，我們終于實現(xiàn)，通過一份活動配置，來控制前端和后端的組件組合。每一個條件、發(fā)貨等動作，都可以隨意動態(tài)組合，參與條件通過“與”、“或”、“非”等組合方式，選擇對應(yīng)的動作，實現(xiàn)活動功能邏輯。

從那時開始，活動開發(fā)變得簡單了不少，需要寫的代碼大幅度減少，基本變成“填寫參數(shù)”的工作。一個活動項目的代碼從之前的1000-2000行，變成了不到100行。

例如，如下圖中，本來需要寫不少邏輯代碼的領(lǐng)取禮包，在前端只變成了一行參數(shù)。

清晰的結(jié)構(gòu)提升了系統(tǒng)可維護性，更為重要的是，活動開發(fā)效率也得到了極大的提升。

在開發(fā)人力不變的情況下，我們活動開發(fā)的效率實現(xiàn)了大幅提升，產(chǎn)品的需求積壓的情況，得到有效的緩解。

2. 高可視化開發(fā)模式（自動化運營）

然而，到了2014年，隨著“移動互聯(lián)網(wǎng)“的快速發(fā)展和逐步成熟，我們也迎來了”手游大爆發(fā)“時代。因為手游的開發(fā)周期更快，幾乎每個月都有很多款新的手游上線，很快手游活動運營的需求出現(xiàn)了爆發(fā)式的增長。AMS承擔(dān)的活動需求，迅速從每個月上線60多個上升到200個的量級，在此背景下，開發(fā)人力再次捉襟見肘，需求的積壓問題進一步加劇。

既然說到開發(fā)人力，就必須介紹一下我們當(dāng)前的活動項目模式。我們騰訊是一家成熟的互聯(lián)網(wǎng)公司，研發(fā)流程的每一個環(huán)節(jié)（設(shè)計、重構(gòu)、開發(fā)、體驗/測試、發(fā)布），都由不同獨立角色完成。一個普通的移動端活動項目耗時，按照最最快速、最理想的模式計算：設(shè)計1天，重構(gòu)1天，開發(fā)2天，體驗/測試1天，也至少需要5天工作日 ，也就是研發(fā)周期至少1周時間。理想是美好的，現(xiàn)實總是殘酷的。在實際項目實施過程中，因為各種資源協(xié)調(diào)和外部因素影響，通常無法達到如此完美的配合，因此，一個普通活動的研發(fā)周期，往往都超過1周。

忽然新增100多個需求，無論對于任何團隊來說，都是一個巨大的壓力。

于是，我們不得不采用另外一種思路，來看待活動運營，是否可以嘗試不投入開發(fā)人力？我們稱之為“自動化運營“， 自動化的本質(zhì)，就是構(gòu)建足夠強大的平臺和工具支撐，讓運營同學(xué)自己完成活動開發(fā)。

前面，我們提到，開發(fā)普通活動時，每一個功能點已經(jīng)變成了一份簡單的配置，而活動開發(fā)的工作，就是將這個配置的活動參數(shù)填入到頁面按鈕上。如果，我們實現(xiàn)一個可視化工具，將這個填寫配置的工作，變成拖拽按鈕的功能，這樣就可以徹底告別“寫代碼“的工作。

最終的結(jié)果，是我們做一個可視化拖拽的活動模板系統(tǒng)。運營同學(xué)只需要經(jīng)過適當(dāng)?shù)呐嘤?xùn)，就能學(xué)會如何使用。首先，運營同學(xué)將活動設(shè)計圖上傳，模板系統(tǒng)自動切圖（完成重構(gòu)工作），然后，配置活動功能，通過拖拽按鈕功能組件（本質(zhì)上是一個p透明蒙層），插入到頁面中。然后點擊體驗和發(fā)布，最終完成活動上線。因為我們的功能組件是早就經(jīng)過嚴(yán)格測試，才提供給運營同學(xué)使用，通常不需要技術(shù)測試同學(xué)來做測試。

因為從那時開始，運營同學(xué)開始大規(guī)模替代開發(fā)、重構(gòu)、測試的工作，然而，她們是一群不了解技術(shù)細節(jié)的人，這里也無形增加了活動的上線風(fēng)險。因此，除了這個活動模板的實現(xiàn)之外，我們還根據(jù)AMS平臺的特性，搭建了一系列的支撐平臺和工具。

簡而言之，就是為了避免“人為的失誤“，人的失誤不能靠人本身來避免，而要靠平臺和程序來保證和檢測。因此，我們建設(shè)了強大而且智能的配置檢查系統(tǒng)和活動數(shù)據(jù)監(jiān)控。舉個例子，本來資源池里有100個禮券，但是，運營同學(xué)誤配置為200個，這個時候平臺就會檢測并且提示運營同學(xué)，這里配置不正確。

自動化運營給我們帶來了研發(fā)流程級別的優(yōu)化，在活動研發(fā)流程中，我減少了重構(gòu)、開發(fā)和測試的流程，使得活動項目研發(fā)周期大幅度縮短，活動項目研發(fā)效率出現(xiàn)質(zhì)的飛躍。手游運營需求的積壓問題，得到根本和徹底的解決。

我們的高效活動開發(fā)模式的構(gòu)建完成，也促使我們的AMS平臺業(yè)務(wù)規(guī)模快速的增長。我們一個月上線的活動項目數(shù)，在2015年10月時，上線活動超過400個，而其中有80%以上屬于運營同學(xué)“開發(fā)“的模板活動。

三、可靠性與性能支撐建設(shè)

我們通過構(gòu)建高效的活動開發(fā)模式，促使我們AMS運營平臺的業(yè)務(wù)規(guī)模和流量規(guī)模，都在過去的三年多時間里，出現(xiàn)了100倍的增長，同時在線的活動超過1000個。與此同時，AMS平臺的可靠性和穩(wěn)定性，也成為至關(guān)重要的指標(biāo)之一，平臺如果出問題，影響面變得很廣。

AMS平臺的架構(gòu)分為四個層級，分別為：入口層、業(yè)務(wù)邏輯層、服務(wù)層、存儲層（CKV的NoSQL存儲），還有一個離線服務(wù)和監(jiān)控系統(tǒng)。

1. 可靠性

活動運營業(yè)務(wù)，對平臺的可靠性非常敏感，因為這里涉及到很多高價值禮包的發(fā)放，部分還涉及支付環(huán)節(jié)，穩(wěn)定壓倒一切。

在保證可用性方面，我們做幾個方面的工作：

在告警監(jiān)控方面，AMS平臺的建設(shè)更為嚴(yán)格，我們力求多渠道告警（rtx、微信、郵件、短信），多維度監(jiān)控（L5、模塊間調(diào)用、自動化測試用例、AMS業(yè)務(wù)監(jiān)控維度等）。即使某些監(jiān)控維度失效，我們同樣可以第一時間發(fā)現(xiàn)問題。當(dāng)然，我們也會控制告警的周期和算法，做到盡量減少騷擾，同時，又能真正發(fā)現(xiàn)系統(tǒng)問題。

可靠性另外的一個挑戰(zhàn)，就是過載保護。不管我們系統(tǒng)擁有多少機器，在某些特殊場景下，終究有過載的風(fēng)險，例如“秒殺“和”定時開啟“之類的推廣面前。AMS當(dāng)前同時在線的活動超過1000，已經(jīng)太多了，這些活動中，偶爾總會有大流量推廣，并且業(yè)務(wù)方甚至根本沒有周知到我們。無論在何種場景下，我們必須做到AMS平臺本身不能”雪崩“，如果集群掛掉，就影響全量用戶，而做過載保護只是拋棄掉了部分用戶請求，大部分用戶還是能夠獲得正常的服務(wù)。

在過載保護方面，我們采取了一些并不復(fù)雜的措施：

2. 秒殺場景的業(yè)務(wù)保護

秒殺在活動運營中，是比較常見的一種參與形式，它帶來的挑戰(zhàn)除了流量沖擊的問題，還會帶來高并發(fā)下的業(yè)務(wù)邏輯安全問題。這個時候，我們必須引入適當(dāng)?shù)逆i機制，來規(guī)避這些問題。它和線程安全是同一類型的問題。

首先是用戶的session鎖，也就是說，同一個子活動功能中，同一個用戶，在前一次發(fā)貨請求結(jié)束之前，禁止第二個請求。之所以要這樣做，是因為，如果同一個用戶發(fā)起兩個并發(fā)請求，在一個臨界時間內(nèi)，可能導(dǎo)致禮包多發(fā)。

例如下圖中的A用戶，在第一個請求成功寫入?yún)⑴c成功標(biāo)志位之前，第二請求是可以通過“條件判斷“，仍然可以進入發(fā)貨環(huán)節(jié)，這樣的話，就可能會讓A用戶獲得2個禮包。

還有一個鎖是基于多個用戶的秒殺保護鎖，場景是類似的，Session鎖，只是變?yōu)槎鄠€并發(fā)用戶，請求同一個禮包，同樣在判斷禮包余量數(shù)目的臨界時間里，有可能產(chǎn)生“超發(fā)“（禮包多發(fā)了）。

問題很明顯，采用鎖當(dāng)然就可以解決，但是，采用何種的鎖機制，又是一個值得思考的問題。因為，業(yè)務(wù)場景不同，選擇的解決方案自然不同。我們從三個不同的思路，來討論秒殺的實現(xiàn)機制。

我們業(yè)務(wù)鎖采用的是樂觀鎖的實現(xiàn)方式，因為我們的一個發(fā)貨流程通常耗時超過100ms，在高并發(fā)下，都容易產(chǎn)生請求積壓，導(dǎo)致我們無法做到實時反饋。我們的實現(xiàn)，確保不管用戶是否請求秒殺成功，都能在500ms內(nèi)獲得實時反饋。并且，我們將這個實現(xiàn)廣泛使用到各個秒殺和搶購活動中，曾經(jīng)支撐過5w/s的秒殺活動，表現(xiàn)非常平穩(wěn)和安全。

四、業(yè)務(wù)安全體系建設(shè)

隨著業(yè)務(wù)規(guī)模的增長，AMS平臺每天發(fā)出去的發(fā)貨操作也越來越多。在非節(jié)假日每天發(fā)貨5000多萬，在高峰的時候，發(fā)貨超過2億。同時，這里活動中含有很多高價值的東西，例如ipad、iphone、高價值虛擬道具，甚至還有一些活動推廣使用現(xiàn)金禮包（財付通到賬）。

如此，我們的業(yè)務(wù)安全比普通的互聯(lián)網(wǎng)產(chǎn)品的要求更高，更嚴(yán)格。

1. 傳統(tǒng)安全打擊維度和惡意用戶

成熟的互聯(lián)網(wǎng)公司通常都會有自己的安全團隊，一般通過數(shù)據(jù)建模的方式，搭建出一個惡意用戶黑名單的數(shù)據(jù)庫，然后持續(xù)維護這些惡意賬號和Ip等信息，更新數(shù)據(jù)。然后，我們這個服務(wù)接入到里面去。惡意工作室手持大量的賬號和Ip，而我們通過這個惡意數(shù)據(jù)庫，將它們攔截掉。

但是，數(shù)據(jù)建模的算法不管如何精細，為了防止誤殺真實用戶，總會存在打擊率的問題，它們通常無法攔截下全部惡意請求，總會有少數(shù)的漏網(wǎng)之魚。

而我們所思考的，就是在這個基礎(chǔ)上，結(jié)合業(yè)務(wù)，增加新的安全保護策略。可能會有很多人會想，追加參與門檻是否可以取得進一步的保護效果呢？例如，在傳統(tǒng)安全打擊策略的基礎(chǔ)上，再加上業(yè)務(wù)限制，例如將活動參與條件設(shè)置為超級會員（20元一個月的付費會員），這樣的話，我們以更高的門檻來攔截惡意請求。

在以前很長一段時間里，我都認為這種方法應(yīng)該是靠譜的，因為提高了參與的門檻。直到有一次，我們捕獲到一批好幾萬的惡意QQ號碼（都是一些號碼很長的垃圾號碼），它們竟然全部都是超級會員，惡意工作室竟然花費了不少錢給它們開通20塊錢一個月的超級會員。從那個時候開始，我開始明白，付費會員身份限制，也是不可靠的。

超級會員的身份帶給這些惡意號碼更多的便利，反而可以給它們獲取更多高價值禮包的機會，將獲得東西兌現(xiàn)成金錢，然后覆蓋掉惡意工作室的“投資成本”。

2. 業(yè)務(wù)安全支撐體系建設(shè)

AMS建設(shè)多個維度，全方面的安全支撐能力。我們將這些安全建設(shè)，又分為四個維度：

關(guān)于我們：

小時光茶社（Tech Teahouse），由Tencent SNG增值產(chǎn)品部技術(shù)團隊創(chuàng)建，用于技術(shù)分享和交流。